實體首部字段

這是包含請求和回應訊息的實體部分，所用來補充內容或相關訊息的字串。

Allow

Allow: GET, HEAD

此字串通知客戶端能夠支援的 Request-URI 指定資料的所有 HTTP 方法。

當伺服器收到不支援的 HTTP 方法，會回傳 405 狀態碼，除此之外還會把所有支援的 HTTP 方法寫進此字段。

Content-Encoding

Content-Encoding: gzip

此字串會告知客戶端伺服器對實體主體的部分選用的內容編碼，內容編碼就是在不遺失實體訊息的狀況下所做的壓縮。

主要採用以下四種編碼：

• gzip
• compress
• deflate
• identity

Conten-Language

此字串告訴客戶端，實體主體主要用的自然語言。

Content-Length

此字串表明實體主體的大小（單位字節）。
對實體主體進行內容編碼傳輸時，就不能再用此字段，因為主體大小的計算方式比較複雜，詳細可參考 RFC2616 的 4.4。

Content-Location

此字段給訊息主體相對應的 URI，與 Location 不同的點在於，此字串表示的是訊息主體回傳資料對應的 URI。

假設使用 Accept-Language 的伺服器發送請求，而回傳的頁面和實際請求的對象不同時，此字串就會寫明對應的 URI。

Content-MD5

此字串的值是由 MD5 算法生成的值，目的在用來檢查主體傳輸過程是否完整，以及再確認是否有傳送到。

對訊息主體執行 MD5 算法，得到會是 128 位元的二進制數字，再通過 Base 64 編碼後寫進此字段。因為 HTTP 字段沒辦法紀錄二進制值，所以需要通過 Base 64 編碼處理，而客戶端會再對訊息主體執行相同的 MD5 算法，比較過後就可以知道訊息的正確性。

這種做法的缺點是無法發現內容有偶發性的改變，或是否被惡意竄改。

Content-Range

Content-Range: bytes 5001-10000/10000

此字串為針對範圍請求，回傳回應所使用，可以告訴客戶端回傳的實體哪個部分符合範圍請求，以字節為單位，表示當前發送部分及整個實體的大小。

Content-Type

此字串說明了實體內的媒體類型，與 Accept 相同使用 type/subtype 的形式。

Expires

這個字段會告訴客戶端資料的失效日期，緩存伺服器在接收此字串的回應之後，會以緩存來回覆此請求。在此字串值的時間以前，回傳的資料副本會一直留存，而當超過指定的時間後，緩存伺服器會轉向跟來源伺服器來請求有效資料。

來源伺服器不希望緩存伺服器對資料進行緩存時，最好在此字串內寫和 header 的 Date 一樣的時間，但是當 Cache-Control 有指定 max-age 時，比起此字串，他會先處理 max-age 的指令。

Last-Modified

此字串指定資料最後修改的時間，一般來說就是 Requst-URI 指定資料被修改的時間，但進行動態資料處理時，此字串可能會變成資料最後修改的時間。

為 Cookie 所服務的首部字段

管理伺服器和客戶端之間狀態的 Cookie ，雖還沒有被 HTTP / 1.1 的 RFC2616 列為標準，但在一般網站已經有廣泛應用。

Cookie 的目的是為了用戶識別和狀態管理，網站為了管理客戶狀態，會透過瀏覽器把資料臨時寫到客戶端的電腦，而客戶端再訪問網站時，就可通過通訊方式取回之前發的 Cookie。

呼叫 Cookie 時，可以檢驗 Cookie 的有效期，以及發送端的網域、路徑等等訊息，所以標準的 Cookie 內的資料不會因來自其他網路和攻擊者的攻擊而洩漏。

Cookie 規格的標準文件有以下：

• 網景公司發布的規格標準
• RFC2109
• RFC2965
• RFC6265

目前最常用的就是 RFC6265，所以接下來以此規格來說。

Cookie 有兩個字串：

• Set-Cookie：開始狀態管理所用的 Cookie 訊息。
• Cookie：伺服端收到的 Cookie 訊息。

Set-Cookie

當伺服器開始管理客戶端的狀態，會事先告知各種訊息：

expires 屬性

• expires 可以發送 Cookie 的有效期
• 沒有指定，默認就是瀏覽器關閉之前
• 一旦 Cookie 從伺服器發送到客戶端，伺服器就不存在可以顯示刪除 Cookie 的方法，但可以通過覆蓋已經過期的 Cookie，一樣可以達到對於客戶端 Cookie 刪除的操作。

path 屬性

可用於限制指定 Cookie 的發送範圍的文件目錄，不過另外有方法可以避開這個限制。

domain

通過 Cookie 的 domain 屬性指定的域名可以做到結尾配對相同。
比方說指定 codingwife.com ，www.codingwife.com 或 www2.codingwife.com 之類的都可以發送 Cookie。

除了指定多個域名發送 Cookie 之外，不指定 domain 更顯得安全。

secure

Set-Cookie: name=value; secure

Cookie 的 secure 僅在 HTTPS 或 SSL 安全連接時，才可會被發送到伺服器。

HttpOnly

這個屬性主要防止 cookie 的擴展功能，它讓 JavaScript 腳本沒辦法取得 Cookie，主要為了防止 XSS 攻擊對 Cookie 的竊取。

Cookie

此字串告訴伺服器，當客戶端想取得 HTTP 狀態管理支援時，就會從請求中包含從伺服器接收到的 Cookie。

其他首部字段

HTTP header 可以自行擴展，所以在瀏覽器上會出現一些非標準的字串，以下就幾種最常用的來做說明。

X-Frame-Options

X-Frame-Options: DENY

此字串是回應 header，控制網站內容在其他網站的 Frame 標籤的顯示問題，主要為了防止點擊劫持。

以下有兩個可以指定的值：

• DENY：拒絕
• SAMEORIGIN：僅同源域名下的頁面配對許可。
  • 舉例：如果指定 codingwife.com 頁面是 SAMEORIGIN，那麼 codingwife.com 下的 frame 都允許可載入該頁面，而其他域名就不行。

X-XSS-Protection

此字串是回應 header，這是一個控制 XSS 對策的一個字串，用於控制瀏覽器 XSS 防護機制的開關。

• 0：將 XSS 過濾設置成無效狀態
• 1：將 XSS 過濾設置成有效狀態

DNT

此字串是請求 header，意思是拒絕個人訊息被收集，表示拒絕被精準廣告追蹤的一種方法。

• 0：同意被追蹤。
• 1：拒絕被追蹤。

這個字串必須要有伺服端對應的支援。

P3P

通過這個技術，可以讓網站上的個人隱私變成一種可以提供程式理解的形式，以保護用戶端隱私。

1. 建立 P3P 隱私
2. 建立對照文件後，保存命名在 w3c/p3p.xml 中。
3. 從 P3P 隱私中建立 Compact policies，輸出到 HTTP 回應中。

資料來源：《圖解 HTTP》 上野宣 人民郵電出版社
筆記純屬推廣及分享，如有侵權，請告知。
Please advise to remove immediately if any infringement caused.